A Blade Server is a type of computing system that allows a user to provision server or other computing resources on an individual card, or “blade”. These blades are housed together with shared resources such as power supplies and cooling fans in a chassis, creating a high-density system with a modular architecture that provides improved flexibility and scalability. Blade Servers can enable the operation of multiple servers in a relatively small footprint, reduce rack complexity, simplify cabling and reduce energy consumption. Blade Servers are often employed in space-constrained and energy conscious environments such as data centers and Internet Service Providers (ISPs).
Physically, a typical Blade Server is a relatively thin, modular electronic circuit board or card, containing one, two, or more processors and memory, which can be inserted into a space-saving chassis with many similar Blade Servers. Typically, each Blade Server will be configured to process a single, dedicated application (such as serving Web pages). In the chassis, each Blade Server will typically share a common high-speed bus such as a Peripheral Component Interconnect (PCI) bus or an Integrated Device Electronics (IDE) bus.
Many applications that serve up Web pages use the Secure Sockets Layer and Transport Layer Security (SSL/TLS) protocols to achieve end-to-end secure communications, particularly in the areas of electronic commerce and financial services. The SSL protocol is described in Netscape Communications Corp, Secure Sockets Layer (SSL) version 3, http://home.netscape.com/eng/ssl3/(November 1996). The TLS protocol is described in Dierks, T., and Allen, C., “The TLS Protocol Version 1.0,” RFC 2246 (January 1999). The most widely used SSL/TLS-enabled protocol today is the Hypertext Transport Protocol (HTTP) encapsulated in an SSL/TLS connection, commonly known as HTTPS. The HTTP protocol is described in “Hypertext Transport Protocol (HTTP) version 1.0, RFC 1945 (May 1996)” and “Hypertext Transport Protocol (HTTP) version 1.1, RFC 2616 (June 1999)”. The SSL/TLS protocol's authentication mechanism typically requires an application serving Web pages to perform computationally expensive mathematical operations, the effects of which are fewer requests serviced per unit of time and higher latency in processing individual requests for Web pages.
The SSL/TLS protocol provides several methods to authenticate both parties to an SSL/TLS connection, the most common of which is the use of Rivest-Shamir-Adleman (RSA) authentication as part of a public key infrastructure (PKI). This is described in RSA Cryptography Standard, PKCS #1 Version 2.0, http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html (Nov. 1, 1993). In common usage, applications serving Web pages will authenticate themselves to clients, but not vice-versa. As part of this procedure, the authenticating party performs a computationally expensive RSA “signing” operation in a full SSL/TLS handshake. This calculation can be time consuming and often comprises one of the largest bottlenecks for applications serving Web pages in relatively short-lived SSL/TLS connections.